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(5 <, Device driver configuration In a computer system ^ 

is,, A comouter system tor dynamic* conjuring ^^^^ aT^pS 
canorises a orocessor 101. a system memory 103. 102 a >d an jnie isi 1} a , u || device driver portion, and 2) a 

"™as feature cards. Each feature card ^^^J^J^SSm system, the device driver stub code .mage ,. 
stub device oriver portion (figure 3) .Upon Jon crt . card .n «»J p « Y memory Tne devic6 dri er s UD code « 

read from the card memory area and transferred ,nto an area rtcomp ran(Jom access mernory 102 . Upon 

, he n executed by the processor of ^^^S^SLl^» driver by allowing memory mapp.n* 3 to the 
execufon. the device driver stub enables ^ ^T^L the procesS or. Upon removal of a feature card from the 
. tui , device driver. The full device dnver ^may ■thjn beaded by P ^ rf fay rf ng 

system without tne system being reset or reinitialised. 
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FIGURE 6c 
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FIGURE 6d 
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FIGURE 4 
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FIGURE 3 
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FIGURE 9 
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FIGURE 11 
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DEVICE DRIVER CONFIG! ' RAT,ONJNArQ N1PlnTR svmf 

BACKOROI [M Q QF THF INVCMTf 
!• Field of iho inwnti« n 

5 Tlie present invention pertains to the field of computer systems 

Specially, the present invention relates to computer systems supporting 
an m.erface for removable system resources and the control of device 
drivers related thereto. 

10 2. Prior An 

" « becoming increasingly more important , 0 dcsi? „ an(J ^ 
compter systems , hat cai5 rs dvnamica „ y ^ 

*" C0 """"" S - S,em °' "I-™* *« opemtal system program 
N-cjo be reset or bootstrap initialed. Dynamic configuration includ« 
-5 U« abtltty ,„ add or remove system resources or specia, feature capabilities 
>vh,!e a computer system i, operating. Ttae system resources and specia! 
features include expansion memory hart,, parallel or serial input/ourput 
0/0) ports, , ead only memory (ROM, or Hash memory expansion boards 
comparer network interface cards, modem cards, sman cards, or Cher 
20 removable system resources or special feature mechanisms. 

Such removable system resources and specia, features are often 
tmplemented in „„ prior „ „ sing , emovab|e ^ 

adhering ,o the Persona, Computer Memory Card International Association 
(PCMCIA,. Sunnyvale, Ca.. Release 2.0 standard. The* PCMCIA feature 
» cards generally comprise electronic microdots within a thin housing 
■ncluding a detachable mu.tiple conductor interface with which the feature 
card may be removably inserted into , slot in a computer housing Once 
ma*, a feature card is accessible ,o and used by ,l,e processor in d» 
computer system. The use of feature cards allows a computer user to select 
» spectftc features or resources from a variety of feature cards offered by a 
computer vendor. In this way, the computer user achieves the desired level 
of functionality without being required to purchase unnecessary resources 
or computer system capabilities. The overall cos, of the computer system 
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for a specific application is thereby optimized. The use of removable 
feature cards is particularly significant for portable computers or lap top 
computers where space constraints increase the need for system resource 
optimization. The design and use of hardware devices under the PCMCIA 
5 standard are well known in the art. It will be apparent to those skilled in 
the art that other implementations of removable system resources are 
possible. 

Virtually all computer systems operate with some sort of operating 
system or software processing logic. The use of an operating system in a 

10 computer system is well-known in the art. The operating system is 
responsible for managing the processing and transfer of information 
between various system resources. One well known technique for managing 
these resources is the use of device drivers. Device drivers are software 
modules comprising processing logic for controlling the low level or 

15 device specific components of a particular computer system resource. For 
example, a device driver may be used for controlling a magnetic disk drive 
device coupled to a computer system. In this example, the device driver 
would control the various hardware specific registers, latches, signals, or 
other components of the magnetic disk drive device. Similarly, other 

20 computer system resources such as serial or parallel input/output (I/O) 
ports, modem devices, computer network interface devices, or memory 
expansion boards are controlled by device drivers. 

In conventional computer systems, device drivers are typically 
loaded into random access memory (RAM) during bootstrap initialization 

25 of the computer system. Many prior an computer systems require that 
device drivers be loaded at initialization time in order for random access 
memory to be allocated properly. Depending upon the complexity of the 
device controlled by the device driver, the device driver itself may be 
relatively small or a very large device driver that consumes many 

30 thousands of bytes of random access memory. Thus, many prior art 
systems require that a full system configuration of resources be installed 
and available at bootstrap initialization time. If system resources or 
interfaces are subsequently added or removed from the system, the 
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...ability ,o access = new,, in»»lled resource or ,he crram access ,„ . „ 
.n. n ||.bte sys.en, resource usually resuhs. 0 .he, prior a„ compu.e, 
systems require ,ha, ,„e compu , tr s , !15n , „ e ^ ^ ^ 

system resources or features are added or removed from ,„e system Slill 
5 o,her sys.ems must ., , cas , b: ^ ^ ^ ^ 

access ,o a new configura.ion of svstem ^ ^ 

computer systems eanno, be readih reconfigured ,o a new arrangement of 

system resources. 

Because prior ar, systems .vpically require ,ha, a f u ,| mie ,„ 
.10 conjuration of resources be estab.ished a. initialization time. ^ «„„.„,.. 
e*,s,s for any or ali system resources ma, may conceivably be used while'a 
computer system is powered up ,o be i„s,a„ed during ,„e w i, iaIi2alion 
Process. This tendency ieads to the tattltaHon of resources tha, are never 
used during a compming session. The ioading and ins.alla.ion of unused 
system resources increases ,i me required for bootstrap i„i t iali z i„ s ,„ 5 
system and reduces U,e available random access memory (RAM), because 
of the RAM space required by unused device drivers. I, is , fterefore 
™pon a „, to instal, in . compute, system oniy those device drivers acuallv' 
needed during . co.nputing session. h some cases, i, may no, be possibie 
-0 ,o load all of ,he device drivers necessary because of ,he random access 
memory storage constraints. 

Some con, P „,er sys.ems in the prior .„ p rovide m£ans 
...terfacmg wi, h removable e.ecronic fea.ure cards. ,„ order ,o mi.iga.e 
«k disadvantages described above, some of Aese computer sys.ems s.ore 
-5 assoc,a,ed device drivers on ,he removab.e electronic fea.ure card i,se„ 
In u,is way, random access memory space wiuin the computer sys.em does 
m need ,o be a |,oc a ,ed for storage of ,he device drive, Moreover 
processing ,ime during ini.iali.a.ion is no, consumed by having ,o ,oad ,he 
ev.ee driver in,o random a ccess memory. Sys.ems 0,a, con^re device 
drivers on ,„e removable feature cards h a ve ,he advance 0 f op.imizing 
memory allocation requirements wkhin the compter sys,em 

Systems ,l, a , configure device drivers on removable fea.ure cards 
however, have several import, disadvan.ages. Firs,, if a fea,ure card is 



8WSDOCIC <GB 2262S2SA > 



removed from Die computer system, the device driver controlling the 
operation of the feature card becomes inaccessible to the computer system. 
In most cases, the computer system requires access to a device driver in 
order to properly terminate the operation of the device prior to removal of 
the feature card. Typically, the computer system does not have sufficient 
time to access the device driver prior to removal of the feature card. 
Thus, system errors often result from an improperly terminated system 
resource. 

Other computer systems having means for interfacing with 
removable electronic feature cards, provide a very limited capability for 
responding to insertion or removal of feature cards during post 
initialization operation of the computer system. Some computer systems do 
not recognize system resources connected to the computer system after the 
bootstrap initialization process has been completed. Other computer 
systems suspend or freeze the operation of the computer system if a system 
resource is removed after initialization is complete. Still other computer 
systems require that the system be powered down or the bootstrap 
initialization process be reinitiated if a new configuration of system 

resources is desired; 

Thus, a better means for dynamically configuring system resources 

in a computer system is needed. 



V 
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Summary nc TlfF Wvrf-T'™ 

n. pw invention „ . compill „ sys|cm h3vjng 
*»„ co„r, suralion for removable sys , sm _ 

- -.v, n| removable sys , em resources ntx syjitm 

-»« tnCude expansion memory bMrfe pjra „ tl M Mria| * 
<«» Pons. read o„ ly memor, (R0M) or J 

compui :; new °' k , "» rf - ««*• -»*«. «*. ».« «*. „ . „: 

emova b e svstem resoofcts or sp£ci>| f5a|ur; m 
10 denoted feature cards or cards). 

A feature card inCudes a card memory area, T*e card memorv area 
Z ~»«^ «« ™,aini„ g card specific functionary 

P-e SS ,o 8 o e ,c. inCudes a de.ee driver for con,ro„i„ 8 ms feanjre card 
>n order ,o avoid ,he problem, encoumered in ^ 

feature card device rfrivpr rt f ,u 

pans- n . r present invention is !eparalsd imo 

P«.. ) run dev.ee driver portion, and 2, a stub device driver portion 
n toil devtce driver provides .„ of tne device driver ,u„cla„ ly 

J..h ,h ful, devtce driver, b „, mai „, v r = !p o„ sible for linkin| , he 

cod- n,. „ ■ „ ■ an < 1 fu " devi « Mver 

used f r t " inf0m,a ' i0 " b ' 0Ck *«" «°™a,io„ 

zrr of proctssins ,osic and da,a ,ta is ^ ■»» ~ 

sv em m ry ^ erlion of . ^ ^ ^ ^ 
TTtt M devtce driver code remains card resident 

Upon insenion of a card into the computer system. „e device driver 
«* «* ,ma E e is read from the card memory « and lransremd „ 
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area of computer system memory. The. device driver stub code is then 
executed by the processor of the computer system from computer system 
random access memory. Conversely, the full device driver code is not 
transferred to the computer system random access memory; rather, the full 
5 device driver is executed while stiU resident on the card. Upon execution, 
the device driver stub enables access to the full card resident device driver 
and allows memory mapping to the full device driver. The full device 
driver may then be activated by the processor. 

The DDIB header comprises a set of information for linking the card 
10 device driver in a linked list with other device drivers and with the 
operating system logic executing within the computer system. By 
traversing the linked list, a particular device driver may be located. Upon 
insertion of a card, the linked list of device drivers is traversed to 
determine whether the device driver stub already resides in said computer 
15 system memory. If so, the operation of copying the device driver stub into 
computer system memory is prevented from occurring. As a card is 
inserted, a card insertion flag is set to indicate the removable system 
resource is coupled to die computer system. 

When a card is removed from the computer system, the linked list of 
20 device driver stubs is traversed to find all device driver stubs associated 
with the removed card. Each associated device driver stub is executed. The 
device driver stub disables access to the removed card by disallowing 
memory mapping to the removed card. The device driver stub is unlinked 
from the linked list of device driver stubs and the card insertion flag is 
25 reset to indicate that the removable system resource has been decoupled 
from the computer system. 

It is, therefore, an object of the present invention to provide a 
computer system in which system resources may be added or removed 
prior to or following bootstrap initialization of the computer system. It is 
30 a further object of the present invention to provide a computer system 
wherein system resources may be reconfigured without powering down the 
computer system. It is a further object of the present invention to provide 
a computer system wherein system resources may be reconfigured without 



reinitiating ,| ie bootstrap iniiializaiion process It is , f„m k- , 

F C5S - n IS 3 further object of the 
P-,„ .nve,,,*,, , 0 provide . compu(er syMm 

Km °' y ° f "* C ° mpU '" ^ <• a , unr , er objec[ of ^ 
-non ,„ provide . compu(ef ^ - 

7 nm ~ y be ■ 

' ° bjK1 ° f Pre «™ ,0 provide . compmer sys , cm 

"»«». an , m erfac. for reiving removable ^ > ' ™ 

may be insened or removed at anv iim, a ■ 

SVSIen , " me dUrm * °P era,ion °< *e compter 

These and other obiecK nf th„ 

6 Present ,nv *ntion will become 



BRIEF DESCRIPTION OF THE DRAWINGS 

Figure 1 is a block diagram of the architecture of a computer system 
in which the present invention operates. 

Figure 2 is an example of a computer housing containing a plurality 
5 of feature card insertion slots. 

Figure 3 is a block diagram of the contents of a removable electronic 
feature card. 

Figure 4 illustrates the content of the Device Driver Information 
Block Header. 

10 Figure 5 illustrates the content of computer system memory as 

related to the content of the feature card memory. 

Figure 6a illustrates the content of the Device Driver Stub RAM 

Area. 

Figure 6b illustrates the content of a stub block. 
15 Figure 6c illustrates the content of a stub header. 

Figure 6d illustrates the content of the stub data area. 
Figures 7-13 are flow charts illustrating the processing logic of the 
preferred embodiment. 



The present invention is a computer !ys , era ^ f ^ 
means for dynamically configuring device drivers „ f , 5m0vab]e em 
resources. ,„ the lowing description. nurntrous spcc|fic 
> fonh ,n order ,o provide . thorough undsrs|an 

-n„on. However, i, bt apparm , o one . f ordina[> sm •> ■ 

1- o U,er crcumstances, we,, known slnjc[ures , ^ ^ • 

Referring now ,„ Figure ,, , block diagrJm of fc ^ 
>n wtach ,he present invention operates is illustrated. 1, wi„ be apparent , 0 

'nose of ordinary skill in ihe art, however that alt-™,- 

1 mat aII emative computer 
s>siem architectures may be employed. ,n General <„rh ,„ 

,,,,.„ , '"'general, such computer svstems 

as illustrated by Figure I comprise a bus 100 f„, 
., ' ' DB for communicatins 

.n,orma,,„„. a processor 10, coup.ed with the bus ,00 fo, processing 
.ronton, and a random access memory device ,02 coupled wlh the b 
100 for storing information and instructions for processor ,0, n t 
processing ,ogic of the present invention is typically stored in a device such 

- n cm access memory ,02 and executed therefrom by processor ,0, . 

n add.tton, a typica, computer system may optionaUy i„c,„de 
sources tncluding a read on,y memory device ,03 coup.ed with the bus 

00, an input device ,04 such as an a.phanumeric i„p u , device or a cursor 
on, d CMpM , o ^ 

~d selections ,o the processor ,01 . a display device ,05 such as . 
*» d, splay terminal or a ,i q „id crysta, disp.ay device coupled ,o lhe bus 
for displaying mhmiuim to , computer user, a da, storage device 
06 such as a magnetic disk and disk drive coupled wi, tbe J m fo 
.ortng information and inactions, an output device ,07 such as a printer 
Jjacstmtle » - *. ,00 for 

formation to a destination e„ema, to the computer system, and 
emovable electronic feature card interface ,08 for electrically removably 
coupling an electronic circuit card to bus 100. 
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Removable fcaiurc cards which may be removably inserted into 
interface 108 generally comprise electronic microcircuits within a thin 
housing including a detachable multiple connector interface with which the 
feature card may be removably inserted into a slot in a computer system 

5 housing. In the preferred embodiment, the feature cards and feature card 
interface 108 used with the present invention adhere to the PCMCIA 
release 2.0 standard for electronic feature cards. Feature cards of this 
form are well known to those of ordinary skill in the art. 

Referring now to Figure 2, an illustration of a computer system 

10 housing having a plurality of feature card interfaces (203, 205, 207, and 
209) is illustrated. As shown, feature cards 211 and 213 may be 
removably inserted and thereby electrically coupled to an interface 108 
within the computer system. This feature card structure facilitates the 
convenient insertion and/or removal of feature cards during the course of a 

15 computing session. 

Referring now to Figure 3, the structure of a typical feature card 
301 is illustrated. Feature card 301 includes an interface 302 with which 
the feature card 301 may be removably electrically coupled to a computer 
system. Feature card 301 also includes a card memory area 303. 'Card 

20 memory area 303 includes software for controlling the remaining card 
specific functionality. This software within card memory area 303, 
including both data and processing logic, includes a device driver for 
controlling the operation of the feature card. 

As described above, it is convenient to store the device driver for a 

25 feature card on the feature card itself. Using this technique, RAM space 
within the computer system does not need to be provided for the card 
device driver and processing time is not consumed in transferring a device 
driver from the card to computer system RAM. Maintaining the card 
device driver on the card itself also achieves the advantage of assuring that 

30 the device driver is always compatible with the card specific functionality. 
There is less chance for a mismatch between the device driver stored in the 
computer system and the card specific functionality provided on the card. 



In order to avoid ,„= ptoblc „, s e „ coun|crcd fa ^ 

:r,;Tn;: e dri : r of ihc prestm ^ - ~ '»■• - 

T ;; »" *>* p- iies all of lhe dtvict driver 

.npute, ™< *».«. ««, stuo is copied inl0 and txecuipd f * 

° °"' PU ' e ' W ™ ««■• — >■ Converse,,, , ht fu „ dev 

"* *' deV '« im " » b '» ,e a ,„re card is , compacl 

P™ess,„ s ,o s ic block . ma „ y sucfc deviM drivcf smbs -P3 

may oe stored in computer syslm random acMss ^ 

>- «»»".,„, «cessive am ou„,s of £omput=r " 

<onf, g ur a „o„ tlhw , . lar85 „ umbtf of d;v|cc driver resident in 

■=omp 0te , system memory without having 10 alloca , = „ 

RAM for the fuII device dHver for e a eh fell T ' " ^ 

Referring again to Figure 7 rar j 

c i i^urc j , card memorv arPQ :ni 

20 H^viro ^ • . r "cjuury area J03 comprises 

,ce dr,ver ,„fom, a ,i on h,oc k (DDIB , header devjc£ 

nfonn a ,,on b ,oc k header 305. comprises formation used for , L I 

:i :r i,h ~ ^ ~ » **■ ~ 

J' 1 "' 4 d "" ibSd C«d ™ory area 303 a ,so comprises , 

deV ' M d "" S ' Ub 307 which is copied to compZ ^ . 

™n,ory and ,he f„„ device driver code 30 9 which remains Jd resilm 
Upon msertion of card 30, into ,he computer system, the device 

30 r 1 ^' " - °' -P- ^ memory 102 . The device 
"ver »* * - <-,ed by the processor of the computer sy I 
rom computer system random ac cess memory. Converse,, fu „ 2 
code 30, is not transferred to ,„e compute, system lorn acce" 
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mcmory 102; rather, the full device driver is executed while still resident 
on card 301. Upon execution, the device driver stub enables access to the 
full card resident device driver 309 and allows memory mapping to the full 
device driver 309. The full device driver 309 may then be activated by the 

5 processor 101. 

Referring now to Figure 4, the content and structure of the device 
driver information block (DDIB) header is illustrated. DDIB header 
comprises a set of information for linking the card device driver with 
operating system logic executing within the computer system. 

10 DDIB header comprises a device driver information block identity 

code 403 that identifies the remaining information as being part of a DDIB 
header. Link data field 405 is used for linking the DDIB with other DDIBs 
(not shown) in the card memory area 303. Device driver stub unique 
identification 407 is a unique value that identifies the device driver stub and 

15 distinguishes the device driver stub from all other device driver stubs. 

The next five DDIB header fields (i.e. fields 41 1, 413, 415, 417, and 
419) are all the same values contained within a standard operating system 
device driver header. Specifically, these five parameters are contained 
within the DOS (Disk Operating System developed by Microsoft, Corp., 

20 Redmond Wa.) device driver header which is well known to those of 
ordinary skill in the an. Device driver linkage information 411, device 
driver attribute information 413, and device driver units and name 419 
comprise device driver identification and linking information used by the 
operating system to identify and link with the corresponding device driver. 

25 The device driver strategy offset 415 and device driver interrupt offset 417 
contain the offset from the beginning of the device driver stub code area. 
These fields are modified by the operation of the present invention as will 
be described below. Device driver stub code offset 421 and device driver 
stub code length 423 provide a means by which the computer system 

30 processing logic may determine where and how large the device driver 
stub code segment is as resident on the feature card. Similarly, device 
driver stub data offset 425 and device driver stub data length 427 provide a 
means for determining where and how large the device driver stub data 
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scrvices 507 provides device driver loader 503 with an identification of ihe 
socket adapter and socket for which the card event interrupt was received. 
Device driver loader 503 then accesses the device driver information block 
(DDIB) header 305 on the newly inserted card as indicated by line 605. By 
5 accessing DDIB header 305, device driver loader 503 gains access to the 
card information described above in connection with Figure 4. 
Specifically, device driver loader 503 may read the device driver stub 
unique identification 407, device driver stub code offset 421, device driver 
stub code length 423, device driver stub data offset 425, and device driver 

10 stub data length 427. Using this information, device driver loader 503 
determines where in card memory area 303 the device driver stub code 
image 307 resides. Once the location and size of device driver stub code 
image 307 is determined as indicated by line 607, device driver loader 503 
copies the contents of device driver stub code image 307 from card 

15 memory area 303 into a portion of device driver stub RAM area 505 as 
indicated by line 609 in Figure 5. The device driver stub code image 307 
is written into device driver stub RAM area 505 and linked into a linked 
list of device driver stubs maintained by device driver loader 503. The 
manner in which the device driver stubs are linked by device driver loader 

20 503 is described in connection with Figures 6a and 6b. 

Referring now to Figure 6a, the device driver stub RAM area 505 is 
illustrated. Device driver stub RAM area 505 comprises memory storage 
area for a plurality of device driver stub blocks. By way of example, 
Figure 6a illustrates stub 1 block 510, stub 2 block 512, stub 3 block 514, 

25 and stub n block 516. It will be apparent to those skilled in the art that any 
number of device driver stub blocks from zero to n may reside within 
device driver stub RAM area 505. It will be also apparent to those skilled 
in the art that the number of stub blocks within device driver stub RAM 
area 505 dynamically changes throughout the usage of the computer 

30 system. Thus, the device driver stubs do not need to be fixed in memory at 
bootstrap initialization time. It should also be noted that the relative size or 
number of memory locations required by each device driver stub block is 
relatively small in comparison to the full device driver code for controlling 
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feature card functionality. The relatively small size of each device driver 
stub block provides the opportunity to store a large number of different 
device driver stubs within device driver stub RAM area 505. 

The device driver stub blocks within device driver stub RAM area 
505 are each composed of three components. Referring now to Figure 6b, 
the three components of each stub block of device driver stub RAM area 
505 is illustrated. Each stub block comprises a stub header 540, stub data 
542, and stub code 544. Stub header 540 is used mainly by operating 
system logic that controls ihe operation of the computer system. 

Referring now to Figure 6c, the content of stub header 540 for each 
stub block is illustrated. Stub header 540 comprises device driver linkage 
information 630, device driver attribute information 632, device driver 
strategy offset 634, device driver interrupt offset 636, and device driver 
units and name 638. The computer system memory 102 resident device 
driver information 630, 632, 634, 636, and 638 of the stub header 540 
corresponds to the device driver information 411; 413, 415, 417, and 419 
of the card resident DDIB header. The DDIB device driver information is 
transferred to the stub header 540 when a stub device driver is loaded. 

Device driver linkage information 630, device driver attribute 
information 632, and device driver units and name 638 comprise device 
driver identification and linking information used by the operating system 
to identify and link with the corresponding device driver. Device driver 
linkage information 630 is used by the operating system to create a 
forward linked list of device drivers as illustrated by lines 519 in Figure 
6a. Using the device driver linkage information 630, the operating system 
518 may access each device driver in the linked list by traversing down the 
list using the device driver linkage information of each device driver stub 
block until the last device driver stub block points back to the operating 
system 518. Stub header 540 also includes a device driver strategy offset 
634 and a device driver interrupt offset 636 which are used to identify the 
entry point to stub code 544 as illustrated by line 546 in Figure 6b. 

Referring now to Figure 6d, the content of stub data 542 is 
illustrated. Stub data 542 comprises pointers 660 and 662 that are used by 
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deviee driver loader 503 for creating a forward and backward linked list 
of device driver stub blocks within device driver stub RAM area 505. 
Pointer 660 is a pointer to the previous device driver stub block in the 
linked list. Pointer 662 is a pointer to the next device driver stub block in 
5 the linked list. This doubly linked list structure is illustrated in Figure 6a 
by lines 517. 

Referring to Figure 6a. device driver loader 503 contains a pointer 
to the first device driver stub block 510 in the linked list. The pointer 662 
of stub 1 block 510 points to stub 2 block 512. Similarly, pointer 660 of 
10 siub 1 block 510 points back to deuce driver loader 503. In a similar 
manner, pointers 660 and 662 of each device driver stub block is used to 
point to the previous and next device driver stub in the linked list. Thus, 
the device driver stubs are forward and backward linked in a linked list. 
The last device driver stub block in the linked list (i.e.. stub n block 516), 
15 points back to device driver loader 503 to complete the doubly linked list. 

Referring again to Figure 6d. stub data 542 also comprises an. 
adapter identification 664 and a socket identification 666. Adapter 
identification 664 and socket identification 666 uniquely identify the 
computer system hardware interface with which the device driver stub is 
20 associated. Device driver stub unique identification 668. which is Hie same 
identification as the feature card resident device driver stub unique 
identification 407 illustrated in Figure 4, uniquely identifies the device 
driver stub associated with the feature card. Card insertion flag 672 is used 
io retain an indication of whether the card associated with the device driver 
25 stub is inserted or removed. Driver specific data area 674 is a memory 
area allocated for use by the device driver stub for storage of its own data. 

Referring now to Figures 7 through 13, flowcharts illustrating the 
processing logic used by the preferred embodiment are illustrated. It will 
be apparent to those skilled in the art that the processing logic described 
30 herein may be executed by processor 101 of the computer system. 

Referring now to Figure 7. the processing logic associated with the 
device driver loader 701 is illustrated. Device driver loader logic 701 
corresponds to device driver loader 503 illustrated in Figures 5 and 6a. 
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have been processed. Once all of the cards in the list of installed cards have 
been processed, processing path 1021 is taken to termination bubble 1027 
where processing for the device driver loader terminates. If each of the 
installed cards in the list of installed cards have not yet been processed, 
5 processing path 1019 is taken to processing block 1023 where the index 
into the list of installed cards is advanced to point to the next installed card 
and processing continues at the bubble labelled G as illustrated in Figure 7. 
At the bubble labelled G, the card insertion processing subfunction is again 
activated for the newly indexed installed card. 
10 Referring now to Figure 9, the processing for a card event service 

routine 1101 is illustrated. Card event service routine 1101 is a software 
routine registered with the operating system at bootstrap initialization of 
the computer system. Card event service routine 1101 is activated when a 
hardware event is detected by the computer system upon the insenion or 
15 removal of a feature card in any socket provided by the computer system. 
Upon activation of card event service routine 1101, the identity of the card 
socket adapter and the card socket corresponding to the hardware event is 
obtained in processing block 1103. If a card insertion event is detected, 
processing path 1107 is taken to processing block 1108 where the card 
20 insertion processing subfunction is activated for the newly installed card. 
Processing then terminates at return bubble 1131. 

Referring again to decision block 1105, if a card has not been 
inserted into a socket, processing path 1109 is taken to decision block 1111. 
If a card removal event is detected, processing path 1115 is taken to 
25 processing block 1119 where the linked list of device driver stubs within 
device driver stub RAM area 505 is traversed in search of a device driver 
stub corresponding to the socket for the removed card. If a device driver 
stub corresponding to the removed card is found, processing path 1125 is 
taken to processing block 1 127 where a card insertion flag in the stub data 
30 is reset to indicate that the corresponding card has been removed. Once the 
card insertion flag for the removed card has been reset, the device driver 
stub corresponding to the removed card is activated in processing block 
1 129. Activation of the device driver stub corresponding to the removed 
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card causes the device driver stub to gracefully terminnte any ongoing 
act,v IIy while the card was installed and disables further access to the 
removed card. The device driver stub is then united from the linked list 
of dev.ce driver -stubs. Upon completion of processing block 1129, control 
5 ,s transferred back to processing block 1 1 19 where the stub linked list is 
again traversed for another device driver stub corresponding to the socket 
for wh.ch a card removal event was detected. Tne loop between processing 
blocks 1 1 19 and 1 1 29 continues for each device driver stub in the linked 
list until every device driver stub of the removed card is processed When 
.0 tins occurs, processing path 11 23 is taken to bubble 1131 where processing 
Tor card event servicing terminates. 

Referring back to decision block 1 1 1 1. if the hardware event causing 
•he activation of card event service routine 1 101. is neither a card insertion 
even, nor a card remova, event, processing path 1, 13 is taken to processing 
.3 block 11,7 where the unidentified event is recorded. Processing then 
terminates at bubble ] 131. 

Referring now ,„ Figurt l0 , caf(j .^.^ 
subfuncion 800 is illustrated. Card insertion pressing m h 
ether from processing b!ock 7,5 illustrated in Figure 7 or process™,, 
» bloc, ll0 . illustrated in Figure ,. Card insenion processing 800 is 
responsibie for comrol.ing the allocation and loading of a device driver 
stub corresponding ,„ a newly inserted feature card. Starting „ processi „ 8 
block 801 . the card memory area of the newly inserted card is accessed If 
a devtce driver information block (DDIB) is present in the card memory 
» area of the newly installed card, processing path 80 5 is taken to processing 
block 807. If no DD,B is present in the card memory area, process™ 
path 803 is taken to the bubble labelled C illustrated in Figure 12 where 
card tnsertion processing terminates a, bubble 1017. Because no. all 
feature cards require a device drive, processing pad, 803 is provided for 
30 those cards that do not require a device driver. 

A. processing block 807. the header of the DDIB of the newly 
mstalled card is read. Decision block 809 tests whether or not ft. device 
dnver stub for the newly installed card has been previously loaded based 
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on the device driver stub unique identification. If this device driver stub 
has been previously loaded, the device driver stub executable code does not 
need to be loaded again. Thus, if the stub has already been previously 
loaded, processing path 811 is taken to decision block 821 where available 
5 space within device driver stub RAM area 505 is checked. If there is 
available RAM space for the device driver stub data and the stub header, 
processing path 825 is taken to the bubble labelled B as illustrated in Figure 
11. If, in decision block 821, there is not enough RAM space available, 
processing path 823 is taken to processing block 824 where an error in 
10 driver loading processing is reported. Card insertion processing then 
terminates through the bubble labelled C as illustrated in Figure 12. 

Referring again to decision block 809, if the device driver stub for 
the newly installed feature card has not been previously loaded, processing 
path 813 is taken to decision block 815 where a test is made to determine if 
15 there is enough space in device driver stub RAM area 505 for the storage 
of the device driver stub executable code, the device driver stub data, and 
the stub header. If there is enough RAM space available, processing path 
819 is taken to the bubble labelled B as illustrated in Figure 11. If, 
however, there is not enough RAM space available as a result of the test 
20 made in decision block 815, processing path 817 is taken to processing 
block 824 where an error in device driver loading processing is reported 
and processing terminates through the bubble labelled C as illustrated in 
Figure 12. 

Referring now to Figure 11, card insertion processing continues at 
25 the bubble labelled B. At this point, it has been determined that sufficient 
space is available in device driver stub RAM area 505 for the storage of the 
device driver stub for the newly inserted feature card. In processing block 
827, a portion of the DDIB header from the newly installed card is copied 
into the preallocated device driver stub RAM area. In particular, fields 
30 41 1, 413, 415, 417, and 419 of the DDIB header are copied into fields 630, 
632, 634, 636, and 638 of the stub header, respectively. An additional 
portion of RAM in the device driver stub RAM area is reserved for device 
driver stub data in processing block 829. The size of this stub data area is 



sncctfted by , parame.er 427 in uhe DD1B header. If .he device driver s,ub 
was not previously loaded from a fea.ure card or a lis! of preloaded device 
driver s.ubs loaded during boo.s.rap initialiaation of the computer svstem 
processing palh 911 is taken , 0 processing block 913. In processing'block 
5 913. .he device driver s.ub executable code is copied from .he newlv 
.ns,alled feature card ,o ,he preaHoca.ed device drive, s.ub RAM area 
wtthin device driver s,„b RAM area 505. The strategy and interrupt 
offsets are loaded in processing block 915 ,o properly reference the newlv 
loaded code. Referring back to decision b.ock 907, if the device driver 
>0 nub was previously loaded from a prior feature card o, an optional 
mmalization preload lis,, processing path 909 is ,ake„ to processing Wock 
910 where the strategy and offset linkage is se, to the previously loaded 
executable code. In this manner, loading a previously loaded device driver 
stub may be prevented. Processing then continues a, processing block 9,7 
A, processing block 9,7. , hc nead£r ^ ^ ^ ^ ^ 

-vtthtn device driver stub RAM area 505 is initia.ized. Initiation of 
these areas includes loading linkage pointers, adapter and socke, 
■dem.ftcation information, and the device driver stub unique identification 
These areas may te loaded by transferring the corresponding information 
20 frotn the card resident DD1B header. A card insertion Hag in me stub data 
■3 se, in processing block 9,9 to indicate that the card is insened into a 
socket and accessible ,o ,he compu.er sys,em. Processing then con.inues a, 
Hie bubble labelled E as illus.raied in Figure 12. 

Referring now ,o Figure ,2, ,he newly i„ s ,a„e d device driver stub is 
* >cded to the iinked lis, of device drivers maintained by .he operating 
system in processing block ,001. Adding me newly installed device driver 
s.ub ,0 this linked lis, involves setting a pcin.er in me s.ub header ,o poin. 
.o .he n„, device driver block in ,he linked lis,. Similarly, me s,ub header 
po.n,er of ,he previous device driver block is se, ,o poin, ,o ,he newl, 
,ns,a„ed device driver s,ub. The device driver s,ub corresponding ,„ ,he 
newly inserted card is activated in processing block 1009. As a resul, of 
-he activation of ,he device driver stub, .he device driver s.ub enables the 
activation of the f„„ device driver code 309 residen, on me newly i„ s , a ,led 



BNSOOCID <GB 2262B2S* > 



Memory capping - the new,y ins.a.ied card is a»-d. Thus the 
l.tware and me card resident device drive, and the card restden. 
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mtm0 rv area for the newly ins,a„ed card, processing pa* ,0.3 - .*» » 

Lonen, device driver rnforma.ion biock is read in process., b, ck 
10 ^Because feature cards nray con.ain .ore .an one s=, of funct.onabty. 
m re than one device driver per card may be presen, U. however n 
I, I device driver infon.ation block is present for the new.y tns.aUe 
1. processing pa. ,0,5 is taken ,o termination bubb.e ,0,7 ,,ere card 

ins-nion processing terminates. 
„ ReLn 8 no,,oFi 6U r=,3. l heprocessin g ,o e icforeacbdev, 

, exanrpie. device driver s.ub processing ,ogic is 
response ,0 the activation of tne device driver stub ,o g ic in process, 
20 I; „» iUustrated - Figure , and in processing block ,00, ,.,s,ra,ed 

in Fi8 °n,!e 2 devic. driver sub is being activated in order ,o initial .he 
operation of the device driver stub after being ,oaded. processing path 
, 07 is taken to decision b.ock ,204. ,f the activation of *e dev.ce rtver 
„ stu b is the «... of a card insertion even,, processing pa* ,206 ,s taken .0 
" processing b.ock .2,0 wbere the card merno^ area of ft. tnsened card - 
ccessed. Any necessary configuration or card partition information ,s 
tained by the device driver stub in processing b.ock ,2,4 Mapptng ,0 
, llc f9 „ device driver resident on the feature card is enabled ,n processing 
,0 block ,2,3. Access to the card resident full device driver ,s enabled m 
res ng biock 12,6. As a resu,, of enab.ing access to the can, res.den. 
vie dnver. processing con.ro, may subse q uen.,y be .ransferd , the 
rd resident device dHver where feature card functionary ma, be 
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Refernng back to decision block 1203, if the device driver stub is 
"0, activated for the purpose of ini.iali^ lhe devjce ^ ^ 
Processtng path ,20 5 is lake „ 10 dscisio „ ^ ^ p ^ ■ 
,s ,a en dunn, the norrna , ODJra , on „ , h£ ^ ^ 

5 m '" a " 2a " 0n — d - '« "* «™. ,he presence of the card 
corresponding ,o the device driver stub is cherts • 
1200 ir, k Jt P roc «sm| block 

'209. If ,he card has been removed, processing path I2U is taken ,o 

processing terminates a, bubble ,2, 9 . ,f. ho , CV er, * e card cor.spond.ng 

ken : V ' Ce ' Ver Mb " S,i " PreSe "' ^ aC,i - P — ^ 
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Although the invention is described herein wi,„ reftrcnce 10 , 
S P=c .c embodiment, man, modifications and variations therein wi 
->y occur to .hose ski.led in ,he m . According,, .„ !uch ^ 
•nd modtficat.ons are induded within the intended scope of the prese 
■nventton as defined by the Mowing claims. 
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CUIHS 

1 . In a computer system having a processor, a system memory, and an 
interface for receiving a removable system resource, a process for 
dynamically configuring device drivers of removable computer system 
resources, said process comprising the steps of: 

receiving an indication that a removable system resource has been 
coupled to said interface, said removable system resource having a 
resource memory, said resource memory containing device driver stub 
processing logic and full device driver processing logic; 

copying said device driver stub processing logic into said system 
memory; 

executing said device driver stub processing logic from said system 
memory; 

enabling access to said full device driver processing logic, said access 
being enabled by said device driver stub processing logic; and 

executing said full device driver processing logic from said resource 
memory. 

2. The process as claimed in Claim 1 wherein said resource memory 
further includes a device driver information block (DDIB) header, said 
process further including the step of copying said DDIB header into said 
system memory. 

3. The process as claimed in Claim 2 wherein said DDIB header includes 
link data and a device driver stub unique identification, said process further 
including the step of linking said device driver stub processing logic with 
different device driver stub processing logic stored in said system memory. 

4. The process as claimed in Claim 1 further including the steps of: 

determining whether said device driver stub processing logic already 
resides in said system memory; and 



preventing said copying s.ep if said" device driver stub processing 
logic already resides in said system memory. 

5. TTie process as claimed in Claim 1 further including the steps of: 
providing a card insertion flag in said system memory; a*d 
setting said card insertion nag when said removable system resource 

is coupled to said interface. 

6- Be process as claimed in Claim 1 .herein said slep of ^ 

■o sa,d full device drive, processing logic further including ,he slcp of 
allow.ng mcmory raapping , 0 said fu „ d;v . ce drjver pro ^ s ^ ^ 

residing in said resource memory. 

7. The process as claimed ,„ Cain, 3 wherein said siep of linking said 
ev,ce driver s.ub processing logic further including ,he s.eps of forward 
total said device driver s,ub processing logic with differ, device drive, 
S,Ub Pr0CeSSi "« l0 8 ic and ba *ward Unking said device driver stub 
processing logic wi,h different device driver srub processing logic. 

8. The process as claimed in Claim I further including the steps of- 
rece,v,„g an indication ,ha, a removable system resource has been 

decoupled from said interface; and 

disabling access ,o said full device driver processing logic, said 

access being enabled by said device driver srub processing logic. 

»• Tie process as claimed in Claim 8 whe,ein said DD1B header includes 
« a,a and a device driver s,»b unique iden.ifica.ion. said process furrter 
mcludmg ,„e s,ep of unlinking M dtvice drjver ^ 

rrom differen, device driver stub processing logic S ,o,ed in said sys.em 

memory. 

10. The process as claimed in Claim 8 further including the steps of- 
providing a card insertion nag in said system memory; and 
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reseuing said card insertion flag when said removable system 
resource is decoupled from said interface. 

11. In a computer system having a processor, a system memory, and an 
interface for receiving a removable system resource, a device for 
dynamically configuring device drivers of removable computer system 
resources, said device comprising: 

means, for receiving an indication that a removable system resource 
has been coupled to said interface, said removable system resource having a 
resource memory, said resource memory containing device driver stub 
processing logic and full device driver processing logic; 

means for copying said device driver stub processing logic into said 
system memory; 

means for executing said device driver stub processing logic from 
said system memory; 

means for enabling access to said full device driver processing logic, 
said access being enabled by said device driver stub processing logic; and 

means for executing said full device driver processing logic from 
said resource memory. 

12. The device as claimed in Claim 11 wherein said resource memory 
further includes a device driver information block (DDIB) header, said 
device further including the means for copying said DDIB header into said 
system memory. 

13. The device as claimed in Claim 12 wherein said DDIB header includes 
link data and a device driver stub unique identification, said device further 
including the means for linking said device driver stub processing logic 
with different device driver stub processing logic stored in said system 
memory. 

14. The device as claimed in Claim 1 1 further including: 



means for dcicnnining wheth; r said'device driver stub processing 
logic already resides in said system memory; and 

means for preventing said copying step if said device driver stub 
processing logic already resides in said system memory. 

15. The device as claimed in Claim II further including: 

a card insertion flag in said system memory; and 
means for setting said card insertion nag when said removable 
system resource is coupled to said interface. 

16. The device as claimed in Claim 11 wherein said means for enabling 
access to said full device driver processing logic further including means 
fpr allowmg memory mapping to said full device driver processing logic 
residing in said resource memory. 

1 7. Tne device as claimed in Claim 13 wherein said means for linking said 
dev.ee dnver stub processing logic further including means for forward 
linking said device driver stub processing logic with different device driver 
stub processing logic and means for backward linking said device driver 
stub processing logic wi.h different device driver stub processing logic. 

18. The device as claimed in Claim 11 further including: 

means for receiving an indication that a removable system resource 
has been decoupled from said interface; and 

means for disabling access to said full device driver processing logic 
said access being enabled by said device driver stub processing logic. 

19. The device as claimed in Claim 18 wherein said DDIB header includes 
link data and a device driver stub unique identification, said device further 
including the mean: for unlinking said device driver stub processing logic 
from different device driver stub processing logic stored in said system 

memory. 
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20. The device as claimed in Claim 18 further including: 

a card insertion flag in said system memory; and 
means for resetting said card insertion flag when said removable 
system resource is decoupled from said interface. 

21. In a computer system having a processor, a system memory, and an 
interface for receiving a removable system resource, a process for 
dynamically configuring device drivers of removable computer system 
resources, substantially as hereinbefore described with reference to 
the accompanying drawings. 

22. In a computer system having a processor, a system memory, and an 
interface for receiving a removable system resource, a device for 
dynamically configuring device drivers of removable ccmputer system 
resources, substantially as hereinbefore described with reference to 
the ccompanying drawings. 
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